The challenge to accessing legacy systems from client locations has been widely recognized, and numerous methodologies have been proposed to provide solutions. Conventional approaches to converting applications for distributed execution center on three main methods: distributed objects/ORBs, event buses, and browser based architectures.
In the distributed object approach, the server data structures that need to be accessed by the client are exposed to an Object Request Broker (ORB). The ORB allows remote processes to access exported objects through proxy objects, which transparently convert invocations of methods into remote procedure calls. Using an ORB based approach has two significant drawbacks:
1. The ORB requires that programmers follow a set of language bindings which dictate the structure and implementation style of code that will be interfaced to the ORB. This structure is never what programmers would have devised on their own. Creating a mapping between an existing data structure and the ORB based objects is an extremely complex process.
2. ORB based distribution translates each method invocation into a series of communications. The simple mapping of a data structure to an ORB-like approach results in large numbers of remote invocations, each of which is expanded into a series of separate communication events. To reduce this communication requires implementing a new layer of server objects which is interposed between the client and the server. Such an intermediate layer reduces bandwidth requirements by providing more coarse-grained operations that return data structures using awkward “by-value” objects. Each invocation still requires multiple communication events because of the complexity of the ORB communication protocols, and programmers are forced to use this awkward CORBA data types for values and proxies.
Browser-based applications are implemented as components that can be embedded within a web browser. These applications communicate with the server through the use of HTTP-family protocols. This approach can be very useful for relatively simple applications, but building complex interactive applications in such a manner is extremely difficult. HTTP is a client-driven, stateless, connectionless protocol, which makes interactive style communication difficult. While it is possible to implement applications in this fashion, they ultimately devolve to an unpleasant combination of HTTP based communication, and ad-hoc TCP/IP connections for necessary communications that are inexpressible in HTTP.
More specifically, inside IBM computing environments, the Component Broker (CB) system and the Enterprise Java Beans (EJBs) approach each provide a rich interface to allow client programs to access legacy systems on servers. However, it is desirable to provide a simple, lightweight, low-technology system that focuses on data access, without requiring the more complex features of larger systems, and for quickly implementing the data-access layer of more complex, full-featured systems like EJBs or CB components.
Alternatively, Microsoft has proposed two strategies towards solving this problem: Active Data Objects (ADOs), and Common Object Model (COM) wrappers. Active Data Objects are similar in design to Enterprise Java Beans and Component broker, providing rich interfaces to legacy databases on server platforms. COM wrappering is a technology for accessing legacy code. It consists of implementing stub code in Microsoft's Common Object Model to allow clients to access the code and/or data in a legacy system through the standard Microsoft object model. One drawback to the Microsoft approach is that it relies on the Microsoft COM infrastructure, such that systems that use this approach must adopt the Microsoft system architecture. In addition, the COM infrastructure is a complex system, which adds significant complexity to systems that use it.
With regard to heterogeneous linked data structures which may reside at client and server locations, there is also a need to provide access and coherence between two distinct data structures that represent the same underlying data which exist in distinct memory spaces on two different computers. Since two such data structures are supposed to represent the same underlying data, any change in one of the data structures needs to be reflected in the other. One key point about this is that while the two structures represent the same underlying data, their actual structure in the memory of the computer need not be identical.
Under the presently available technology, the two isolated data structures can be handled using a technology called distributed shared memory (DSM). DSM, however, has a lot of requirements including:
1. requiring operating system support
2. requiring very high speed, high bandwidth network access
3. requiring laborious programming using special libraries.
What is desired is a system and method which allows programmers to implement linked data structures manually, using a reasonably easy mechanism which requires no special support from the operating system and which only requires a low-speed low-bandwidth network connection.
What is desirable, therefore, and what is an object of the present invention, is to provide a lightweight solution which relies on a very small, low-tech infrastructure to facilitate communications and access among distinct computing entities.
Another object of the invention is to provide a lightweight method and system which will facilitate implementing ADOs and COM wrappers for legacy systems.
Yet another object of the present invention is to provide a system and method for providing post hoc access to legacy applications and data.
Still another object is to provide a method and apparatus which allows interactive applications to be implemented across the Internet.
Another object of the invention is to provide a method and apparatus for programmers to build high performance distributed applications with low bandwidth requirements.
Yet another object of the present invention is to provide a method for building clients that can access legacy systems.